1. Field of the Invention
The present invention relates to a multiple operating system version software generating device for generating software for different versions of an operating system and a multiple operating system version software generation support program and method relating to the same, more particularly relates to a multiple operating system version software generating device which compiles and links source programs and environment files for the generated software in accordance with the versions of the operating system and a multiple operating system version generation support program and method relating to the same.
2. Description of the Related Art
In recent years, almost all software used in personal computers, servers, personal digital assistants (PDAs), etc. are designed to run on specific versions of operating systems. To generate software running on a specific version of an operating system, it is necessary to develop a source program defining the functions unique to that software, convert that source program as required for that specific version of the operating system by a compiler, and link it to a library etc. required for that version of the operating system. In this way, to generate software running on a certain operating system, it is necessary compile the source program, link to a library, etc. for each of the many versions of the operating system.
The library differs depending on the type of the operating system. Further, the library, developer kit, application protocol interface (API), etc. of the compiler differs for each version of the operating system.
For example, there are three main methods for generating software able to be run on the Windows® operating system. The first is the method of designating the API called the “Software Development Kit (SDK)” as the library. This method utilizes the set of the library and headers for calling up “Win32” (API required for making computer execute processing in Windows® operating system). Software generated utilizing the SDK directly designates Win32 for control of a processor, so enables a processor to execute detailed processing.
The second is the method of designating the Microsoft Foundation Class (MFC), .NET, or other class library as the library. A “class” is a set of a data structure and processing. Unnecessary information is not divulged outside, therefore this is effective when preparing a library for shared use by a number of programmers. In addition, this has features such as variable declaration at any location, multiple definition for changing the functions of operators, and acquisition and release of dynamic memory. This method may be said to be optimal for medium size and larger software development.
Further, a library based on that class, that is, a “class library”, forms an abstract high grade interface. For example, one class of one type of class library, that is, the MFC, may cover five to 20 SDK functions. For that reason, a single call to the class library enables targeted processing to be simply executed. This method is in one respect restricted in terms of control of processing of the processor by the SDK, but has the great advantage of enabling the manhours spent in development work to be slashed.
The usual method for utilization of such a class library is use of a compile tool using a class library to simplify development of a source code, for example, Visual C++®, Visual Studio.NET®, etc. Such a compile tool is provided with a class library in advance and enables addition of a third party class library for compile and link operations. In addition, a batch command file etc. may be used to designate a specific class library, specific dynamic link library (DLL) of SDK or Win32, or API from outside that compile tool.
The above-mentioned library designation methods for generating software able to run on the Windows® operating system do not have to be used alone. They may also be combined. That is, it is possible to use the SDK API for part of the software and use the MFC or other class library for part.
Further, development of such software running on the Windows® operating system requires designation of the SDK, MFC, or other library required for utilization of the Windows® operating system. This is not an issue limited to the Windows® operating system. A similar technique is required for Linux® or Unix® as well.
The third technique is the technique of eliminating the restrictions of such operating system-dependent development and developing software without dependency on the operating system. This technique is made possible by JAVA®. However, JAVA® converts the source code once to an intermediate code and then has that intermediate code executed by a JVM (Java Virtual Machine), so compared with C++ and other native languages, is inferior in terms of the speed of the processing. Further, it is not good at detailed computer processing using Win32. For that reason, when for example high speed processing of a driver etc. and fine control of computer hardware are required, development by JAVA® is unsuitable. Further, in development of software for which high speed processing etc. is not sought as well, the fact is that programmers mastering development languages other than JAVA® will not use JAVA® for development.
Due to the above-mentioned reasons etc., when using an operating system-dependent development language, it is necessary to prepare a different environment for each version of the operating system when developing software designed to run on different versions of the operating system. Further, a different computer is required for each different version of the operating system, so there is the problem that the capital costs for the computers and the work space for the computers increase.
Further, in that case, the source files are stored dispersed among a plurality of computers. For that reason, when source files are changed, it becomes necessary to ensure that the source files be the same in the plurality of environments. However, source files are frequently modified due to the usually required debugging of software after compilation. Therefore, ensuring that the source files are identical in the multiple environments becomes difficult. As a result, sometimes differences arise in the source files. In such a case, the software generated by compiling and linking such differing source files will suffer from the problems of differences in functions for the different versions of the operating systems, insufficient debugging, etc.
Further, to generate software for different versions of an operating system, setting information regarding the compile and link operations such as which libraries to link to or which part of which source program to compile becomes necessary for each version of the operating system. This setting information becomes more complex the greater the number of types and sizes of the libraries linked to in the software. In many cases, when generating the software, it is necessary to manually designate the compile and link setting information to generate the software. Further, when testing the software, that manual setting work has to be repeated for each version of the operating system. Therefore, there is the risk of the developers making errors in the generation of the software.
In the past, a system for automatically generating programs for different types of computers was proposed (for example, see Japanese Patent Publication (A) No. 2002-076886). While this was designed to automatically generate programs, it focused on reutilizing and automatically generating software for different hardware. No method was proposed for automatically generating a source program to deal with different versions of an operating system.
Further, in the past, a multiple operating system application generating system was proposed for automatically converting an application from an original operating system to a new operating system (for example, see Japanese Patent Publication (A) No. 9-204302). However, no specific means was proposed for automatic conversion for different versions of the same operating system.